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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 7/12/1 1 appealing from the Office action mailed 3/24/1 1 . 



Application/Control Number: 10/690,605 Page 3 

Art Unit: 2436 

(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings which 
will directly affect or be directly affected by or have a bearing on the Board's decision in the pending 
appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

No amendment after final has been filed. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 



(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 
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(8) Evidence Relied Upon 



20020038340 



Whipple 



08-2001 



6594823 



Corbin 



09-2000 



(9) Grounds of Rejection 



Claim Rejections - 35 USC §103 



1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims 1 -4, and 6-1 8 are rejected under 35 U.S.C. 1 03(a) as being unpatentable 
over Whipple et al., US PGP No. 20020038340, and further in view of Corbin, US 
Patent No. 6594823. 

As per claims 1,10, and 18, Whipple teaches: 

A system for implementing a policy in a network, said system comprising: 

a plurality of device-agnostic policy implementations, in which the device-agnostic policy implementations 
include non-security policy implementations; 
[see paragraph 5, request from client] 

[see paragraphs 1 7 and 20 for examples of the requests that may be made] 

[see paragraph 16, wherein communication from clients are translated into an appropriate internal 
format for the HUB API. Examiner views the internal formats from that are appropriate for the 
HUB API as device-agnostic policy implementations. Said formats are device agnostic because 
they are not specific to the clients but rather formatted from the clients' specific formats into 
formats that are suitable for the HUB.] 
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a plurality of network devices, at least two of said devices being dissimilar, wherein a type of network 
device associated with a received device-agnostic policy implementation is identified by pars i ng tags of 
data from sa i d r e c ei v e d d e v i c e- agnost i c po li cy i mp le m e ntat i on r e pr e s e nt e d using Extensible Markup 
Language (XML); and 

[see paragraphs 5 and 6 wherein a client communicates a network API request in a native format. 
The request is translated into a internal format to an application server. A return value is later 
sent to the client after it is translated from the internal format back into a native format. It is also 
cited that remote client may interact with the hub system using XML. 

[see paragraph 15 wherein hub and client system may include firewalls, which applicant's 
specification cites as an example of a network device] 



a plurality of device translators, each device translator corresponding to a respective one of said plurality 

of network devices and one of said plurality of device-agnostic policy implementations, at least two of said 

device translators being dissimilar, each of said plurality of device translators being loaded after said type 

of network device is identified to translate said received device-agnostic policy implementation into 

corresponding device-specific implementations, 

[see paragraphs 23 and 24, wherein a network API request (NAPI request) is made from the 
client to the HUB. The client request is first interpreted to ascertain the format of the request 
(XML, EDI, JAVA, etc.). Once this is done, an adapter is chosen to handle the request. The 
adapter is capable of translating the NAPI request into an internal format readable by the HUB. 
Once translated into an internal format, a return value can be sent to the client. Before this can 
be done, an adapter is used to translate from an internal format into the native format of the 
original NAPI request. 

Examiner views the adapters as the claimed device translators. It is clear that the translators 
correspond to the plurality of network devices because they are suitable for translating from the 
native formats of the devices into an internal format and vice versa. It is also clear that the device 
translators are dissimilar because each translator is capable of translating different formats. It is 
further clear that the translators are loaded after the type of network device is identified because 
prior to the device being identified, it would be unknown what type of format the request is. 

wherein subsequent additions or maintenance of any of said plurality of network devices and any of said 

plurality of device-agnostic policy implementations are provided using device-agnostic files. 

[examiner views this limitation as citing that any changes or additions to the way a device 
translator interacts with a network device and its corresponding device-agnostic policy 
implementation are provided using device-agnostic files. As cited above, device-agnostic is 
viewed to be analogous to an internal format. Since the adapters of the Whipple reference are 
maintained by the HUB, it is clear that any changes or additions to the adapters are provided 
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using an internal format. This is in line with applicant's specification because non-vendor specific 
files can be made for various devices without tailoring the code to a specific vendor.] 

The Whipple reference has been discussed above. While Whipple teaches the identification of device 
agnostic policy implementations, Whipple is mute in teaching that the identification of the type of network 
device being associated with a received device-agnostic policy implementation is done by parsing tags of 
data. For this limitation, examiner relies on the Corbin reference. 

Corbin teaches a method which includes parsing the tag of each element to determine the name and type 
of the variable represented by the element (see col. 4, lines 38-67, and col. 5, lines 1-49). Examiner 
views this as analogous to applicant's claimed identifying by parsing tags of data, it would have been 
obvious to one of ordinary skill in the art to modify the Whipple invention to include the parsing taught by 
Corbin because the Whipple invention includes usage of a plurality of different programming languages 
and it would be advantageous to represent the high level programming language data structures in a 
markup language. Parsing of the tags in XML as described by Corbin would afford a uniform language 
that all applicable languages can be translated into. 

As per claims 2 and 13, Whipple teaches: 

The system according to claim 1 , wherein said device-agnostic policy implementation is selected from the 
group consisting of firewall, Virtual Private Network, Java 2 Enterprise Edition Application, and custom 
operating system. 

[see paragraph 6] 

As per claims 3 and 14, Whipple teaches: 

The system according to claim 1 , wherein said device-agnostic policy implementation implements a policy 
selected from the group consisting of access control, quality of service, backup, and availability. 
[see paragraphs 17, 20, and 28] 
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As per claims 4 and 12, Whipple teaches: 

The system according to claim 1 , wherein said device translators are represented by Extensible 
Stylesheet Language (XSL) code. 
[see paragraphs 18 and 23] 

As per claims 11, Whipple teaches: 

The system according to claim 1 , wherein said device-agnostic policy implementation is Extensible 
Markup Language (XML) code. 

[see paragraphs 18 and 23] 

As per claims 6, Whipple teaches: 

The system according to claim 3, wherein said policy is represented by Extensible Markup Language 
(XML) code. 

[see paragraphs 18 and 23] 

As per claims 7 and 15, Whipple teaches: 

The system according to claim 1 , wherein the device-specific implementation is represented by Command 
Line Interface (CLI) code. 

[see paragraph 23, "native format'] 

As per claims 8 and 16, Whipple teaches: 

The system according to claim 1 , wherein the device-specific implementation is represented by 
Application Programming Interface (API) code. 
[see paragraph 16] 
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As per claims 9 and 17, Whipple teaches: 

The system according to claim 1 , wherein the device-specific implementation is represented by 
Java code. 

[see paragraph 18] 



(10) Response to Argument 

I. Rejection of claims 1 -4 and 6-1 8 under 35 USC 1 03 
(A) WHIPPLE 

(A1) Appellant's understanding of what Whipple teaches. 

Appellant is arguing that the Whipple reference does not teach translating 
from a device specific format into a device agnostic format because 
Whipple teaches translating from a native format into another native 
format. 

Examiner respectfully disagrees. Appellant is arguing that the Whipple 
reference does not teach translating from a device specific format into a 
device agnostic format because Whipple teaches translating from a native 
format into another native format. Appellant's interpretation of the Whipple 
reference is only partially correct. Whipple does indeed teach translating 
from a native format into another native format but Whipple further teaches 
that the native format is first translated into a internal format before being 
translated into another native format. Examiner views the native formats 
as device specific and the internal format as device agnostic. The native 
formats are specific to each client while the internal format may be 
translated into any native format. The internal format allows the system to 
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facilitate communication between clients which operate on a variety of 
native formats because each format may be translated into an internal 
format. This is all explained in paragraph 5 of the Whipple reference. 

(B) DIFFERENCES BETWEEN WHIPPLE AND CLAIM 1 

(B1) "Appellants respectfully submit that Whipple determines Whipple's adapter by 
reading a file wrapper instead of "wherein a type of network device associated with a 
received device-agnostic policy implantation is identified by parsing tags of data from said 
received device-agnostic policy implementation represented using Extensible Markup 
Language (XML)," as recited by independent Claim 1 . Further, the Office Action states 
that Whipple does not teach "parsing tags of data from said received device agnostic 
policy implementation represented..." as recited. Appellants respectfully agree." 

It appears appellant is arguing that the determination of the adapter is 
performed by reading a file wrapper instead being identified by parsing 
tags. As cited in the previous final rejection, Whipple does not identify the 
adapter by parsing tags. The Corbin reference was cited to teach this 
limitation. Appellant does not offer any other argument pertaining to the 
differences between Whipple and claim 1. 

(C) NO MOTIVATION TO COMBINE WHIPPLE WITH ANY OTHER ART 

(C1 ) Appellants respectfully submit that Whipple does not teach or suggest "a plurality of 
device-agnostic policy implementations.. .a plurality of device translators, each device 
translator corresponding to a respective one of said plurality of network devices. ..each of 
said plurality of device translators translating said device-agnostic policy implementation 
into corresponding device- specific implementations," as recited by independent Claim 1 . 
It is examiner's understanding of applicant's invention that applicant is 
claiming a system wherein code is written that is non-vendor specific. A 



Application/Control Number: 10/690,605 Page 10 

Art Unit: 2436 

translator is then built that translate this code into a vendor specific code. 
Multiple translators are built for each type of vendor specific code 
(applicant's specification, paragraph 20). Examiner contends that Whipple 
teaches the same embodiments. Whipple takes code of a specific native 
format and translates it into an internal format. As explained in the 
previous action, the internal format is not vendor specific and thus is 
viewed as device agnostic. Any kind of code from any native format can be 
translated by the system taught by Whipple into an internal format. The 
internal format code is then processed by individual adapters into specific 
native formats which examiner views as the claimed vendor specific code. 
(C2) Further, Appellants respectfully submit that Whipple teaches away from 
"...translating said device-agnostic policy implementation into corresponding device- 
specific implementations." For example, as discussed herein, Appellants understand 
Whipple to require translating the parameters from one native format into another native 
format in order to achieve Whipple's intended purpose is to facilitate communications 
between clients where the communications involve electronic market places such as 
business-to-consumer ("B2C") or business-to- business ("B2B") with different sets of 
software applications (see Whipple title, 0003 lines 1-5 quoted herein). Appellants 
respectfully submit that requiring translation of parameters from one native format into 
another native format teaches away from "...translating said device-agnostic policy 
implementation into corresponding device-specific implementations." 

As explained above, appellant has misinterpreted the Whipple reference 
and completely ignored the fact that Whipple teaches translating native 
formats into an internal format. Once the code is translated into an internal 
format, it is then translated into any native format depending on the client 
that is to receive the response. The translation from an internal format into 
a native format is exactly what applicant is claiming in the limitation 
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"translating said device-agnostic (internal format) into corresponding 
device specific (native format) implementations... " 

(C3) Second, Appellants understand Whipple to teach that there is an adapter for each 
requesting client's native format since Whipple teaches selecting an adapter based on 
the requesting client's native format where the adapter converts parameters from one 
native format into another native format (see Whipple 0023, 0016 lines 10-14 quoted 
herein). Appellants respectfully submit that an adaptor for each requesting client's native 
format where the adapter converts parameters from one native format into another native 
format does not teach or suggest "each device translator corresponding to a respective 
one of said plurality of network devices.. .each of said plurality of device translators 
translating said device-agnostic policy implementation into corresponding device- specific 
implementations," as recited by independent Claim 1 . Further, Appellants respectfully 
submit that selecting an adapter based on the requesting client's native format where the 
adapter converts parameters from one native format into another native format (see 
Whipple 0023, 0016 lines 10-1 4 quoted herein) teaches away from "each device 
translator corresponding to a respective one of said plurality of network devices. ..each of 
said plurality of device translators translating said device-agnostic policy implementation 
into corresponding device-specific implementations," as recited by independent Claim 1 . 
Appellants respectfully submit that since Whipple teaches away from Claim 1 , there is no 
motivation to combine Whipple with any other asserted art, such as Corbin. 

The adaptors mentioned by Appellant are used to translate the parameters 
from an internal format into various client native formats. This is exactly 
what appellant is claiming in the limitation, "each device translator 
(adaptor) corresponding to a respective one of said plurality of network 
devices (clients)... each of said plurality of device translators (adaptors) 
translating said device -agnostic policy implementation (internal format 
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parameters) into corresponding device-specific implementations (native 
format parameters). This does not teach away from the claimed limitations 
because it teaches exactly the claim limitations. Since Whipple does not 
teach away from claim 1, there is motivation to combine the Whipple 
reference with the Corbin reference. 

(D) CORBIN 

(D1 ) Appellant argues that Corbin does not cure the deficiencies of the Whipple 
reference. 

The claimed deficiencies of the Whipple reference have been discussed 
above and thus it is reasonable to combine the Whipple reference with the 
Corbin reference 

(E) RESPONSE TO ARGUMENTS SECTION 

(E1) Appellants respectfully agree with the Office Action's assertion in the first paragraph 
on page 4 that Whipple is directed to communications between the clients and the HUB 
involve translating formats of the respective communications. Therefore, the Office Action 
has admitted in the first paragraph on page 4 that Whipple is not directed to translating 
code of a specific native format and into an internal format as the Office Action contended 
at lines 1 0-1 1 of paragraph 1 on page 2. The Office Action states on page 3 lines 1 -2, 
"Applicant is arguing that Whipple translates from a device specific policy into another 
device specific policy." Appellants respectfully submit that this is a mischaracterization of 
Appellants' statements. Appellants have not argued that Whipple teaches "policies" or 
"implementations" as recited. Instead, Appellants have stated that Whipple is directed to 
wrapping communications and translating formats of communications. 
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First, it is unclear how translating code from an internal format into a native 
format is different than what is claimed by appellant. Second, the Whipple 
reference teaches translating parameters or code from one format into 
another. Applied to the claim limitations, Whipple teaches translating code 
from an internal format into code that is in a native format. The format 
itself is not translated; the code is translated into different formats. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related Appeals 
and Interferences section of this examiner's answer. 



For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
/Daniel L. Hoang/ 
Examiner, Art Unit 2436 

Conferees: 
/Nasser Moazzami/ 

Supervisory Patent Examiner, Art Unit 2436 
/Eleni A Shiferaw/ 

Supervisory Patent Examiner, Art Unit 2437 



